Pull request overview

This PR adds dynamic QEMU boot configuration to the Starry build script and introduces x86_64-only rbpf JIT support by allocating executable kernel memory for JIT-compiled BPF programs.

Changes:

• Apply dynamic platform QEMU boot settings when preparing QEMU args in axbuild.
• Add a kernel-side executable memory mapping helper for rbpf JIT on x86_64.
• Enable rbpf JIT compilation/execution on x86_64 and route execution through the JIT path.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 4 comments.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Review 总结

变更内容

本 PR 包含两部分修改：

1. App QEMU 启动流程对齐 (scripts/axbuild/src/starry/mod.rs)：在 app_qemu() 的两条代码路径中补充调用 apply_dynamic_platform_qemu_boot。原 dev 分支中该函数已在 starry/test.rs、starry/rootfs.rs、arceos/mod.rs 等 20+ 处调用，但 starry/mod.rs 的 app QEMU 路径遗漏了，导致 x86_64 app 案例缺少 UEFI/bin 处理和 snapshot drive 重写。

2. BPF JIT 内存 RAII 管理 (perf/mod.rs + perf/bpf.rs)：新增 BPFJitMemory 结构体，通过 ax_mm::kernel_aspace() 分配可执行内核内存，并使用 RAII Drop 自动 unmap。OwnedEbpfVm 中按正确字段顺序持有 _jit_exec_memory，确保 VM 析构在内存释放之前。x86_64 使用 JIT 编译执行，非 x86 架构回退到解释器。

实现逻辑

• axbuild 修改：两处 qemu::apply_dynamic_platform_qemu_boot(&mut qemu, &cargo) 调用位于 rootfs 补丁和 snapshot 参数之后、QEMU 启动之前，与现有 starry/test.rs 和 starry/rootfs.rs 的调用位置一致。导入路径 qemu:: 通过 use crate::test::{case as qemu_case, qemu} 正确解析。
• BPF JIT 修改：字段顺序 vm → _jit_exec_memory → _prog 确保 Rust Drop 以逆序执行（prog 先于 JIT memory 先于 vm 已经完成）。as_static_mut_slice 的 SAFETY 注释正确描述了生命周期契约。execute_with_ptregs 委托给 self.execute_program() 而非直接调用 self.vm.execute_program()，正确路由到 JIT/解释器选择逻辑。

验证结果

• cargo fmt --check：无法单独检查 PR 变更文件（同模块 uprobe.rs 存在 Rust 2024 let-chain 语法，pre-existing），但 diff 中代码格式与现有风格一致。
• 无 Cargo.toml 变更，无 [patch.crates-io]。
• CI 状态：该 PR 刚创建，暂无 CI 检查运行（check_runs 为空）。
• 无已有 review 评论。

重复/重叠分析

• 未发现其他 open PR 修改相同文件或覆盖相同功能。
• starry/test.rs 和 starry/rootfs.rs 中已有的 apply_dynamic_platform_qemu_boot 调用是不同路径，不冲突。
• PR #1038 (nginx CI) 完全不相关。

安全与设计评估

• BPFJitMemory::new(1) 分配 1 页 (4KB)。TODO 注释承认需要更精确的大小计算，但当前作为初始实现可接受。
• MappingFlags::READ | MappingFlags::WRITE | MappingFlags::EXECUTE：W+X 内核内存是安全关注点，但 JIT 编译必需。内存生命周期由 RAII 严格管理。
• vm.set_jit_exec_memory(jit_slice).unwrap() 可能在 API 异常时 panic，但 rbpf 的 JIT 注册在有效内存下预期成功。

结论

修改正确、最小化、与现有代码库模式一致，无阻塞性问题。APPROVE。

Powered by mimo-v2.5-pro

Review 总结

变更内容

本 PR 包含两部分修改：

1. App QEMU 启动流程对齐 (scripts/axbuild/src/starry/mod.rs)：在 app_qemu() 的两条代码路径中补充调用 apply_dynamic_platform_qemu_boot。原 dev 分支中该函数已在 starry/test.rs、starry/rootfs.rs 等处调用，但 starry/mod.rs 的 app QEMU 路径遗漏了，导致 x86_64 app 案例缺少 UEFI/bin 处理和 snapshot drive 重写。两处调用位置（rootfs 补丁之后、QEMU 启动之前）与现有 test.rs 和 rootfs.rs 一致。

2. BPF JIT 内存 RAII 管理 (perf/mod.rs + perf/bpf.rs)：新增 BPFJitMemory 结构体，通过 ax_mm::kernel_aspace() 分配可执行内核内存并使用 RAII Drop 自动 unmap。OwnedEbpfVm 中按正确字段顺序持有 _jit_exec_memory，确保 VM 析构在内存释放之前。x86_64 使用 JIT 编译执行，非 x86 架构回退到解释器。

CI 状态

CI 状态为 pending（尚无 check runs）。本地验证：cargo fmt --check -p axbuild 和 cargo fmt --check -p starry-kernel 均通过。无 CI 失败。

前序 Review 评论

• Copilot (4 条 inline comments)：已在当前版本中解决——unwrap() 改为 .map_err()；JIT 内存从 1 页增加到 4 页（16KB）并保留 TODO；BPFJitMemory 通过 #[allow(unused)] 处理非 x86_64 编译警告（使用侧已有 #[cfg(target_arch)] 门控）。W+X 映射为 JIT 必需，作为初始实现可接受。
• mai-team-app (APPROVE)：与本次 review 结论一致。

安全与设计评估

• 字段顺序 vm → _jit_exec_memory → _prog 确保 Drop 以逆序执行，保证正确性。
• as_static_mut_slice() 的 SAFETY 注释正确描述了生命周期契约。
• execute_with_ptregs 改为调用 self.execute_program() 而非直接调用 self.vm.execute_program()，正确路由到 JIT/解释器选择逻辑。
• Drop::expect 与同模块已有模式一致（如 PERF_FILE.get().expect(...)）。
• W+X 内核内存安全影响有限，内存生命周期由 RAII 严格管理。

重叠 PR

未发现其他 open PR 修改相同文件或覆盖相同功能。

结论

修改正确、最小化、与现有代码库模式一致，Copilot 前序 review 已解决。无阻塞性问题。APPROVE。

Powered by mimo-v2.5-pro

本次 review 结论：APPROVE。

这个 PR 有两部分修改：一是把 starry app qemu 的两条 app 启动路径补上 apply_dynamic_platform_qemu_boot，使 x86_64 动态平台 app case 与普通 Starry QEMU/test/rootfs 路径一样走 UEFI/bin 启动并把全局 -snapshot 转成 drive 级 snapshot=on；二是在 x86_64 下为 rbpf JIT 分配由 OwnedEbpfVm 持有的可执行内核映射，并通过字段顺序保证 VM 先于 JIT 映射和 BPF 程序析构，非 x86_64 仍走解释器。

我检查了当前 head 596f12e7764b92afbe07e03e2c4605de4947d560、现有 review threads 和 CI 状态。GitHub 当前没有 reported checks，因此没有可接受的远端 CI 覆盖；Copilot 的 4 条旧线程当前均已标记 resolved，其中 unwrap() 和 1 页 JIT buffer 已在代码中修正，非 x86_64 编译风险通过本地 clippy 矩阵验证未复现。W+X JIT 映射仍是后续可改进点，不过当前内核已有类似 kprobe exec mapping 模式，且本 PR 的主要目标是修复 rbpf JIT 内存生命周期，不把它作为本次阻塞项。

本地验证：

• cargo fmt --check 通过。
• cargo xtask clippy --package axbuild 通过。
• cargo xtask clippy --package starry-kernel 14 个 feature check 全部通过。
• cargo xtask starry app qemu -t ebpf/sched_trace --arch x86_64 在 PR head 上通过；实际 QEMU 命令使用 OVMF/ESP/bin 启动，guest 中 /usr/bin/sched_trace 运行并输出 SCHED_TRACE_PASS，记录到 2479 条 sched trace records、7 个 distinct next tids。
• 同一命令在当前 origin/dev 上作为 red-check 失败：QEMU 仍用 -kernel .../starryos 直接加载，报 Error loading uncompressed kernel without PVH ELF Note。这验证了 app QEMU boot-flow 修复不是只靠 build 通过。
• git diff --check origin/dev...HEAD 通过。

重复/重叠分析：base 分支已有 apply_dynamic_platform_qemu_boot 的普通 Starry QEMU/test/rootfs 覆盖和单元测试，但 app qemu 路径漏调，PR 补的位置与现有路径一致。相关 open PR 中 #1140/#1141/#1142/#1163 是更大的自研 eBPF JIT backend/测试栈，其中 #1141 会改动 perf/bpf.rs 的执行分发，#1163 增加 JIT smoke 测试；它们与本 PR 属于同一 eBPF 方向，存在后续合并冲突/重放风险，但不是重复实现。当前 PR 只修复 dev 分支上 rbpf JIT memory ownership 和 app qemu boot path，范围更小，可以独立合入。

剩余注意点：后续如果继续推进自研 JIT backend，建议把 BPFJitMemory 的 W+X 策略、JIT buffer 大小估算、以及 #1163 的 JIT smoke coverage 一并重新评估；这些是后续安全/健壮性工作，不阻塞当前修复。